2008 R2 servers. i have a server named server1.domain, it has a folder on its c drive named folder1. folder1 is shared but that's not relevant since i'm currently RDPed to the box making changes. folder1 grants various permissions to five AD groups and two local groups: server1\administrators (full control) and server1\users (read&execute, List, Read). server1\users contains all users in the domain, so i don't want to grant this group any access. i want to control access with the 5 AD groups. server1\administrators contains domain\domain admins, which includes domain\user1. if i remove server1\users from the ACL of folder1, suddenly user1 can't access folder1 anymore. even though user1 is a domain admin and domain admins are in server1\administrators, and server1\administrators have full control of folder1. user1 gets a prompt that says "you don't currently have permission to access this folder" but can click "continue" to get access to the folder, which means his account is explicitly added to the ACL. if i log in with the local administrator account, i can access folder1. this makes no sense to me. even if i shift+right-click the folder icon in the task tray and choose "run as administrator" when i'm logged in as user1, i still can't access c:\folder. even if i explicitly add user1 to the local administrators group instead of relying on the nesting of domain admins. what's going on here? if i have enough permissions to add myself to the ACL of folder1, why can't i open folder1?

update: even odder, user1 *can* open folder1 remotely via its share name. so to recap: user1 is a domain admin which makes him a local administrator on server1. server1\administrators have full NTFS control of c:\folder1. user1 can open \\server1\folder1. user1 can RDP to server1, cannot open c:\folder1 without a prompt to add himself to the ACL, but can delete c:\folder1 with no questions asked.

update: even odder, user1 *can* open folder1 remotely via its share name. so to recap: user1 is a domain admin which makes him a local administrator on server1. server1\administrators have full NTFS control of c:\folder1. user1 can open \\server1\folder1. user1 can RDP to server1, cannot open c:\folder1 without a prompt to add himself to the ACL, but can delete c:\folder1 with no questions asked. Can you enumerate the permissions on the folders for us. Post both results please for each enumeration. Share Permissions Run Net Share {Sharename} to enumerate the permissions for the share Net Share = lists all shares and sharenames Net Share folder1 = Lists share path, max users, caching, and permissions NTFS Permissions Run Icacls.exe {localsharedir} to enumerate the NTFS permissions. icacles c:\folder1 Steve Kline Microsoft Certified IT Professional: Server Administrator Microsoft Certified Technology Specialist: Active Directory, Network Infrastructure, Application Platform, Windows 7 Microsoft Certified Product Specialist & Network Product Specialist Red Hat Certified System Administrator Microsoft Community Contributor Award 2011 All opinions expressed on my own behalf and not that of my company. This posting is "as is" without warranties and confers no rights.

C:\Windows\system32>icacls c:\testfolder c:\testfolder CREATOR OWNER:(OI)(CI)(IO)(F) NT AUTHORITY\SYSTEM:(OI)(CI)(F) BUILTIN\Administrators:(OI)(CI)(F) Successfully processed 1 files; Failed processing 0 files this test folder is not shared. we'll just focus on the local NTFS access. i can't open c:\testfolder when i'm RDPed to server1, but i can open \\server1\c$\testfolder from my workstation.

Typically when you create a share... if a file server... use Share and Storage Management. I use "Share and Storage Management" to create the shares because it allows you to enable "Access-based Enumeration" on the share. Thus if the user doesn't have permission to the file, they just don't see it period. Takes temptation out of the way for users who get curious and trip off access denied alerts. Share Permissions should be: "Everyone" or "Domain Users" and you can even use "Authenticated Users" - Full Permissions NTFS Permissions should be: Explicit with least privilege. Example: Corporate share (sg implies security group below) Corporate - Share = "Authenticated Users" Full permission Corporate - NTFS = Domain Users - Read & Execute Corporate\Sales - NTFS = Sales Mgmt Sg = Full permission - All Files and Folders Corporate\Sales - NTFS = Sales Users Sg = Read/Write/Modify - This folder and files only Corporate\Sales\Performance - NTFS = Sales Mgmt Sg = Full Permissions Corporate\Sales\Performance Becky = Sales Manager - Sales mgmt sg & Sales user sg Greg = Sales Associate - Sales user sg Dave = Marketing - Marketing user sg Greg can access the Share "Corporate", can See the Sales folder, can read/write/modify files in the Sales Folder, but does not see Performance Dave can access the Share "Corporate", cannot see the Sales Folder at all in the Corporate Share. Becky can access the Share "Corporate", can see the Sales folder, can read/write/modify files in the Sales Folder, and can see Files and Folders inside Performance. Maybe this example will shed some light on what you might be missing. Best of Luck to you and I'll check back soon for your results.Steve Kline Microsoft Certified IT Professional: Server Administrator Microsoft Certified Technology Specialist: Active Directory, Network Infrastructure, Application Platform, Windows 7 Microsoft Certified Product Specialist & Network Product Specialist Red Hat Certified System Administrator Microsoft® Community Contributor Award 2011 All opinions expressed on my own behalf and not that of my company. This posting is "as is" without warranties and confers no rights.

this is interesting, although i have UAC set to "never notify" which i think is as close as i can get to "disabling" UAC in 2008 R2. http://technet.microsoft.com/en-us/library/cc731677(WS.10).aspx What's New for Access Control in Windows Server 2008 Changes to tokens When a user who is a member of the Administrators group in Windows XP or Windows Server 2003 logs on to a computer, that user's token contains the Administrators group SID, and the user has the same permission as the Administrators group. In Windows Server 2008 and Windows Vista, if UAC is enabled, the Administrators SID is still present in the token but is set to Deny only. When performing access control, such an entry in the token is used only to deny accessin other words, to match "Deny" ACEs. Any "Allow" ACEs for that SID are ignored. That means that you are not truly an administrator all the time, even if you log on to the computer as one. If UAC is disabled, then a user who is a member of the Administrators group has a token containing the Administrators group SID.

C:\Windows\system32>icacls c:\testfolder c:\testfolder CREATOR OWNER:(OI)(CI)(IO)(F) NT AUTHORITY\SYSTEM:(OI)(CI)(F) BUILTIN\Administrators:(OI)(CI)(F) Successfully processed 1 files; Failed processing 0 files this test folder is not shared. we'll just focus on the local NTFS access. i can't open c:\testfolder when i'm RDPed to server1, but i can open \\server1\c$\testfolder from my workstation. This is probably a UAC restriction or native Group Policy restriction. Off the top of my head I'm not 100% sure I'll check through my notes. I ran into this before. Steve Kline Microsoft Certified IT Professional: Server Administrator Microsoft Certified Technology Specialist: Active Directory, Network Infrastructure, Application Platform, Windows 7 Microsoft Certified Product Specialist & Network Product Specialist Red Hat Certified System Administrator Microsoft® Community Contributor Award 2011 All opinions expressed on my own behalf and not that of my company. This posting is "as is" without warranties and confers no rights.

Steve, again, the share is completely irrelevant to my issue. i am *only* concerned with my domain administrator account's inability to access c:\testfolder *Locally* when logged in locally to server1. i have created a completely new test folder to play around with and it is not shared and it is not going to be shared. i only mentioned the share initially to illustrate the weirdness that NTFS is allowing me to remotely access the same folder that it won't let me access locally.

Steve, again, the share is completely irrelevant to my issue. i am *only* concerned with my domain administrator account's inability to access c:\testfolder *Locally* when logged in locally to server1. i have created a completely new test folder to play around with and it is not shared and it is not going to be shared. i only mentioned the share initially to illustrate the weirdness that NTFS is allowing me to remotely access the same folder that it won't let me access locally. I gathered that.. Using Resultant Set of Policy in GPMC on the domain controller, can you run a resultant set of policy to your Terminal server with the user account in question?Steve Kline Microsoft Certified IT Professional: Server Administrator Microsoft Certified Technology Specialist: Active Directory, Network Infrastructure, Application Platform, Windows 7 Microsoft Certified Product Specialist & Network Product Specialist Red Hat Certified System Administrator Microsoft® Community Contributor Award 2011 All opinions expressed on my own behalf and not that of my company. This posting is "as is" without warranties and confers no rights.

the tried-and-true trick of re-disabling UAC after it's already been disabled seems to have fixed it (for now). i've used this a lot in the past when machines wouldn't let me install software: 1. raise UAC from the bottom rung "never notify" to the next higher rung. click ok. 2. go back into UAC and lower it back down to "never notify," click ok twice. 3. reboot. icacls c:\testfolder looks the same as it did before, but now i can access it with my domain account.

http://technet.microsoft.com/en-us/library/dd835564(WS.10).aspx What I have done to prevent this is enabled all administrators to run in Admin Mode. GPEDIT.MSC - since its for the Terminal Server only... Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options | Scroll down to the bottom. "User Account Control: Run all administrators in Admin Approval Mode: Enabled" "User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode: Prompt for Consent for non-Windows Binaries" "User Account Control: Behavior of the elevation prompt for standard users: Prompt for Credentials: Enabled" "User Account Control: Only Elevate UIAccess Applications that are installed in secure locations: Enabled" "User Account Control: Switch to the Secure desktop when prompting for Elevation: Enabled" "User Account Control: Virtualize file and registry write failures to Per-user Locations: Enabled" UAC Mode: Default - Notify me only when programs try to make changes to my computer Steve Kline Microsoft Certified IT Professional: Server Administrator Microsoft Certified Technology Specialist: Active Directory, Network Infrastructure, Application Platform, Windows 7 Microsoft Certified Product Specialist & Network Product Specialist Red Hat Certified System Administrator Microsoft Community Contributor Award 2011 All opinions expressed on my own behalf and not that of my company. This posting is "as is" without warranties and confers no rights.

As Steve said, accounts in local Administrators group are working as standard accounts. Although Administrators group has permission on a folder, if we did not allow the account "work as Administrator", it still does not have admin permission, so it will fail to access the folder. A workaround is to create a group for accounts in local Administrators group and give the new group same permission as local Admins group. Or as Steve said, "run admins in administrators mode".TechNet Subscriber Support in forum |If you have any feedback on our support, please contact tnmff@microsoft.com.

As Steve said, accounts in local Administrators group are working as standard accounts. Although Administrators group has permission on a folder, if we did not allow the account "work as Administrator", it still does not have admin permission, so it will fail to access the folder. A workaround is to create a group for accounts in local Administrators group and give the new group same permission as local Admins group. Or as Steve said, "run admins in administrators mode".TechNet Subscriber Support in forum |If you have any feedback on our support, please contact tnmff@microsoft.com.